Technical field
The embodiments herein generally relate to a method of synchronizing and integrating a data. The embodiments herein particularly relate to a method of synchronizing the data between the source and the target devices. The embodiments herein more particularly relate to a system and method for synchronization of links and attachments during synchronization between two computing devices.
Description of the Related Art
In the existing attachment synchronization techniques, the attachments which are not added by integration are not deleted. As a result of which, the following use cases do not work. This is required to support a bidirectional attachment synchronization where the attachment can be added/removed from any of the system in integration. An attachment is carried out by the user when file 1 with updated Entity A is added to a System1. The attachment is carried out, when the changes of entity A is synchronized in System2. The attachment is carried out by the user, when the attachment file1 is deleted from entity A in the System2, and changes in System1 are synchronized. Since the file 1 in System1 is not added by integration user, it is Jo not removed as part of delete operation in System2. Moreover, when the entity A is polled again from System1, the File1, which was deleted by an X user, is again added in the System2.
For the synchronization of the links and attachments, there are various constraints from the different system API to support fully functional bidirectional sync of the links and attachments. The constraints are that many of the systems doesn't maintain the history for the links, updated operations i.e. link added, updated or removed; many of the systems doesn't provide information about which user added links mans of the systems doesn't provide information about at what time the link was added, and many of system don't provide any history of link change information and of those which provide history of link change information, many of the systems doesn't provide the history of link change information from both the linked entities. Even though Child entity e2 is added on the entity e1, the link history information is available from the entity e2 only but not from the e1. As a result, no child history information is available during syncing of e1, many of the systems don't allow adding link from the both entities and many of the systems don't support attachment update operation.
Hence, there is a need for a system and method for synchronization of links and attachments during synchronization between at-least two systems. There is also a need for a method for properly handling recovery of links updates during bidirectional synchronization. Further, in case of addition of link between entities in one system and the link between the entities was removed in the other system, and then “link remove” must be synced to the other system. When the link is added between the entities in one system and the opposite entity is updated to remove the link in the other system, then “link remove” must be synced to the other system. When the link, is updated in the source system during the sync operation and the link is removed in the other system, then these results as conflict in the link. While syncing historical data for the system which does not support history, then an eventual synchronization of the link is happened, when the linked entity actually get synced to the other system. Further, there is also need for a method to recovery data in case of the failure in between the processing of the links.
Further, there is also a need for a method for efficiently handling recovery of attachments during bidirectional synchronization. Further, when the attachments are added in the source system which is synced to other system and its content was updated in the target system, then the original attachment must be updated with the new content. Further, in case where attachment was added in the source system, which is synced to other system and delete operation as performed in the target system, then the original attachment must be deleted. Further, in case where attachment was added in the source system which is synced, the attachment was updated in the source system and the attachment is synced with a new content in target system even though target system is not ha mg support for the update attachment, their exits a need for a method for handling recovery of attachments. Further, in case where attachment was added in source system, same attachment was with different content was added in the other system, and then this conflict must be detected for the attachment. Further, in case where attachment was updated in the source system, the same attachment was with different content was updated in the other system, and then this conflict must be detected for the attachment. Further, in case where attachment was updated in the source system, the same attachment was deleted in the other system, and then this conflict must be detected for the attachment.
The above mentioned shortcomings, disadvantages and problems are addressed herein and which will be understood by reading and studying the following specification.